The quantified self is really quite a hot topic. Ivan Kirigin talks about it in his post <a href="http://blog.kirigin.com/personal-analytics">here</a> as a potential startup idea. I’ve created something simple I’d like to share with all of you.

It is really quite simple, but also very flexible. Before I explain what it is, I’ll cover some of the conceptual reasoning behind the solution.

I believe that to do lists are generally quite hard to deal with, and overall don’t help my productivity. They require me to return to them over and over throughout the day, managing them, and often only serve as a place to mark things as done (rather than a place to ensure that I am being productive).

However, I don’t mind prompts. I don’t mind alerts. Certainly too many of irrelevant alerts can be annoying. But if I am motivated to use the alerts, I will.

As a developer, I am used to constant feedback. I am used to my machine telling me when I have compile errors. I’m used to having reports. These reports are what I take action on. To-do lists stay dormant until I put effort into them. The same can be said for calorie tracking applications. The same can be said for most tracking applications.

So, I created a small script to ask me a random question. I set up a YAML file to track my answers and the dates of my answers. I then created a simple plist file to load the script every 8 minutes via <code>launchctl</code>. This will give me about 50 data points per workday.

While they may be simple data points, and while the questions will repeat, the concept is simple: my computer asks me a question, and tracks my answer for me. My answers can be arbitrary; I also have two types of questions. One is directly actionable, the other is subjective. (“Tell your wife you love her.” vs “What have you eaten today?”)

Here is the Ruby code:

```ruby
#!/Users/jonathancutrell/.rvm/rubies/ruby-2.0.0-p247/bin/ruby
require 'yaml'
y = YAML::load_file(File.join(__dir__, "stretchr.yml"))
if (rand(10).to_f/10.0).round == 1
 @msgs = y["msgs"]
 @msg = @msgs.sample
 ret = `osascript -e 'set question to display dialog "#{@msg}" buttons {"Nope", "Did it"}'`
 ans = ret.split(":")[1]
else
 @questions = y["questions"]
 @msg = @questions.sample
 ret=`osascript -e 'set question to display dialog "#{@msg}" default answer ""' -e 'text returned of result' 2&gt;/dev/null`
 ans = ret
end
@answers = y["answers"]
@answers[@msg] ||= []
@answers[@msg]&lt;&lt; [ ans, Time.now ]
File.open('stretchr.yml', 'w+') do |file|
 puts file.write(y.to_yaml)
end
```

And here’s the yaml file.

```
---
msgs:
- Stand up and stretch.
- Live healthy, think healthy
- Tell your wife you love her.
- Do something to show appreciation to your coworkers and employees.
- Text a family member.
- Value, now. Stop doing things that don't matter.
- Have you kissed your wife today?
questions:
- Is your desk clean?
- Have you had 10 minutes of quiet thinking time today?
- What word are you thinking of right now?
- Who was the last person you spoke to?
- Is Hacker News open?
- What are you building now for tomorrow?
- Text a family member.
- What have you eaten today?
- On a scale from 1 to 10, how energetic are you?
- On a scale from 1 to 10, how productive do you feel today?
- How many hours did you sleep last night?
answers: {}
```

And finally the plist.

```
&lt;?xml version="1.0" encoding="UTF-8"?&gt;
&lt;!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"&gt;
&lt;plist version="1.0"&gt;
&lt;dict&gt;
 &lt;key&gt;Label&lt;/key&gt;
 &lt;string&gt;org.jcutrell.stretchr&lt;/string&gt;
 &lt;key&gt;ProgramArguments&lt;/key&gt;
 &lt;array&gt;
 &lt;string&gt;/Users/jonathancutrell/stretchr.sh&lt;/string&gt;
 &lt;/array&gt;
 &lt;key&gt;StartInterval&lt;/key&gt;
 &lt;integer&gt;480&lt;/integer&gt;
&lt;/dict&gt;
&lt;/plist&gt;
```

Some of these you can clearly see come from personal goals. Some of them, though, are much more related to aggregating some sort of arbitrary data. Later, I hope to gain some kind of insights from this into very specific areas of my life.

Notice the name <code>stretchr.sh</code> - this was originally built to be a simple reminder to stand up and stretch at my desk. I would go hours on end without stretching simply because it wasn’t on my mind. So many things we should, could, and want to do go undone because we simply let them slip our mind. I’m interested to see how much of an impact these more consistent reminders will have.

It’s obviously very easy to add new data points. Of course, as you add more questions or imperative messages, it’s more likely that you will have more time between data points on average, assuming an even distribution of the random range generator over time.

It would be easy to take this YAML data somewhere else, like for instance to JSON to be fed into something like D3:

```
require 'yaml'
require 'json'
y = YAML::load_file(File.join(__dir__, "stretchr.yml")) # I think this may be v&gt;=2.0
puts y.to_json
```

Interested in doing something similar? Or interested in making this more than it is? Let me know. I’d love to let this grow.

My Solution for Quantified Self: Prompted Data Aggregation

It's in every engineering leader's job description: "hold people accountable."

Accountability is a funny thing to use as a critical skill for a high level leader, because in many ways the core of what this is saying is "do the job."

Let's talk about the message under the message here a bit; what are these companies really looking for when they say you need to hold people accountable?

Let's imagine a scenario to play this out.

We have an imaginary EM Marcus. Marcus is responsible for three teams who are delivering work on critical projects.

Each team has a few engineers and a product manager. Marcus is responsible for reporting on the team's progress.

Teams A and B are smooth sailing. Team A is brand new with onboarding engineers, so they don't have a significant project on their plates other than getting up to speed. Team B is well staffed and their project is running along slightly ahead of schedule.

Team C, though, is struggling. They are under-resourced, and their project is running behind by a couple weeks.

So, where and how does accountability show up in this picture? I'm going to present three different forms of accountability and how it applies to the situation.



I've decided to publish my "Work With Me" doc in a place I own as I generally believe my working style largely remains the same across job roles. That said, this "work with me" doc is subject to change as my role shifts.

In general, my roles tend to be in some kind of engineering leadership position, and usually I have people that report to me. So, this document will be biased toward that perspective.

### Leadership Style
I believe that leadership starts with clarity. Clarity in goals, motivation, expectations, and situation. If there is a lack of clarity, the primary job of a great leader is to find or create that clarity. Clear is kind.

**What values do I represent as a leader?**
- **Trust** - I believe trust is the foundation of all positive working relationships. By default, I "trust but verify." When we lose trust, it becomes the top priority to resolve that.
- **Communication** - the conduit of our work together is communication. This is the medium of clarity; if our communication is breaking down, all of our work will follow. Good communication is necessary to maintain trust.
- **Responsibility** - The hallmark of a good leader is the ability to accept responsibility in any scenario. Responsibility does not mean "accepting the blame for someone else's mistake" - it is forward-facing. Responsibility in almost all circumstances means stepping into a situation and owning the next step.
- **Proof over gut** - great leaders don't just trust their gut. They take it into account, along with a bunch of other checks and balances that are observations of reality. Going with your gut is usually a tradeoff of efficiency. For big decisions, or for repeated processes, the more we can integrate our intuition with observed measurements, the more accurate and informed our decisions can be.
- **Action and Grit** - In every circumstance, I imagine I am in the pilot seat. I'm not along for the ride; I make things happen, I am a part of the solution, and life doesn't just happen to me.
	- Note that when you see a lack of this, it is often because of fear. Inaction comes often when psychological safety is lacking, because people are afraid that failure in their actions might result in negative outcomes for them. This is a disabling state that returns to the governing factor: trust.
- **Humility** - Humility means being honest about the reality of our own limitations. This is at an individual level as well as a team level. The best leaders I've worked with were the first to say "I don't know", and the first to admit "I screwed up." In every case, humility worked in their favor and did not undermine their leadership; I aspire to this level of transparency.
- **Confronting Reality** - Much of our jobs as managers is to find and manage the *reality* of a given situation. (Pro tip - This is really just an extension of humility.)
	- For example, we have a major delivery due at the end of the month, but based on our performance data we are trending to deliver end of next month, and we just lost one engineer to attrition. The reality of this situation is that there is a very slim chance we will deliver on time. Trying to get around this by using poor management tactics or rhetoric is the hallmark of an immature leadership culture.
	- The best working environments are the ones where we can observe truth together and decide what to do about it - not ones where we try to spin the situation to look better for us.

**What do I expect from other managers?**
- **High integrity** - say what you mean, do what you say.
- **Focus on what you can do** - It's often easy to see what's wrong. It's harder to decide what to do about it. But that's what a great manager does!
- **Clarity** - if you need something, ask for it! If you are concerned about something, make it known.
- **Human spirit.** - we don't have to approach most problems like we are saving the world. Yes, it's important to focus and do good work together, but sometimes the best thing we can do is laugh together. Managers set the tone for the workplace, and if all people see is seriousness, challenge, demand, and cold calculation, they will leave their own humanity at home when they come to work.
- **When data is available, us it.** - Ignoring data is like putting your head in the sand. Backing up your decisions with data is a part of what it means to confront hard truths.

**What do I expect from engineers?**
- **Do the right thing.** Often this means doing what you feel is the best option in the scenario; not cutting corners. However, sometimes the "right thing" can be ambiguous or dependent on the situation, which is when we talk about it as a team. Doing the right thing also extends to our moral and ethical considerations as a team.
- **Make your work visible.** Work that isn't documented is hard to track. The organization and you benefit from making your work visible, both because it is shown to help with productivity and clarity, and because it provides a history of contribution.
	- Note: this isn't *just* about tracking tickets in Jira (though that's part of this) - it's also about making clear what your decisions are, and providing a paper trail for the soft parts of your work that don't fit in a ticket.
- **Learning mode is always-on.** The industry changes quickly. What you need to know to be successful is always evolving. It is critical for engineers to pick up new hard and soft skills to grow their careers.
- **Focus on impact.** We don't bike shed over unimportant details. When we disagree, we focus on what it will take to move forward, not on bolstering arguments further. "Impact" means different things in different circumstances; part of this skill is learning how to identify *what* impact matters in a given situation.
- **Adaptability.** Every organization I've been a part of has undergone some kind of major change. Being able to ride through the changes is an important part of what it means to be a successful engineer.
	- Note that I'm *not* telling you you have to agree with every change; rather, that organizations will always be changing, and holding on to previous notions of an org produces friction that may not be useful to you, and instead may hinder your growth in that org.
- **Commit to your team.** We win and lose together. We build our agreements, we stick to commitments, we support each other. We are not individuals working near each other - we work *together.*
- **Take responsibility for aligning your work with your career goals.** Your biggest opportunities will come because you are ready to grab them. I am a good advocate for your success, but ultimately you are your *greatest* advocate.

I bring my [personal values](https://jonathancutrell.com/values) into my work; you can expect those values to drive my own behaviors. Not all of them translate in every context, which is why I'm keeping them separated for the sake of this document, but the discussion below may have some significant overlap with those values.

**Overall, you can expect me to be people-first in my approach.** This is an easy thing to say (and lots of people claim some version of this), but in practice what does this mean?

**Humans are not machines.** We are organic, head, heart, and soul. Our goals of working together are ultimately subordinate to our individual humanity, our personal search for meaning, our own full experience. Our emotions - fear, excitement, joy, loss, anticipation... all of these are more powerful than any OKR or Jira board can capture. This means that predictions about humans are less reliable than predictions about machines. Over the course of many humans, predictions become more reliable, but individual outliers are not only possible - they are fundamental to what it means to be human.


Jonathan Cutrell